Usually you will want to leave the Linux kernel alone except when performing a major
upgrade, installing a new networking component (such as NFS or NIS), or installing a new
device driver that has special kernel requirements. The details of the process used to
install the kernel drivers are usually supplied with the software. Because this isn't
always the case, though, this chapter should give you a good idea of the general process
for working with the kernel.
Don't modify the kernel without knowing what you are doing. If you damage the source code or configuration information, your kernel may be unusable, and in the worst cases, your filesystem may be affected. Take care and follow instructions carefully. keep in mind that this chapter only covers the basics of kernel manipulation.
The several versions of Linux in common use have a few inconsistencies between them.
For that reason, the exact instructions supplied in the following sections may not work
with your version of Linux. The general approach is the same, however, and only the
directory or utility names may be different. Most versions of Linux supply documentation
that lists the recompilation process and the locations of the source code and compiled
programs.
Before doing anything with the kernel or utilities, make sure you have a good set of emergency boot disks and a complete backup on tape or floppy disk. Although the process of modifying the kernel is not difficult, it does cause problems every now and again that can leave you stranded without a working system. Boot disks are the best way to recover, so make at least one extra set.
Because the kernel is compiled with the C compiler supplied as part of Linux, the
latter part of this chapter looks at the C compiler and its flags and how you can use it
to your advantage. This information isn't meant to be a complete reference to the C
system, of course, but it should be useful for some basic manipulations you may require
when modifying the kernel (or any other source code compiled by C).
Linux is a dynamic operating system. New releases of the kernel or parts of the
operating system that can be linked into the kernel are made available at regular
intervals to users. Whether you want to upgrade to the new releases usually depends on the
features or bug fixes that the new release offers. You will probably have to relink the
kernel when you add new software, unless the software is loaded as a utility or device
driver.
Avoid upgrading your system with every new release, for a couple of reasons. The most
common problem with constant upgrades is that you may be stuck with a new software package
that causes backward compatibility problems with your existing system or that has a major
problem with it. Most new releases of software wipe out existing configuration
information, so you will have to reconfigure the packages that are being installed from
scratch. Also, the frequency with which new releases are made available is so high that
you can probably spend more time loading and recompiling kernels and utilities than using
the system. Read the release notes carefully to ensure that the release is worth the
installation time and trouble. Remember that few installations proceed smoothly!
The best advice is to upgrade only once or twice a year, and only when there is a new
feature or enhancement that will make a significant difference to the way you use Linux.
It's tempting to always have the latest and newest versions of the operating system, but
there is a lot to be said for having a stable, functioning operating system, too.
If you do upgrade to a new release, bear in mind that you don't have to upgrade
everything. The last few Linux releases have changed only about five percent of the
operating system with each new major package upgrade. Instead of replacing the entire
system, just install those parts that will have a definite effect, such as the kernel,
compilers and their libraries, and frequently used utilities. This method saves time and
reconfiguration.
Upgrading, replacing, or adding new code to the kernel is usually a simple process. You
obtain the source for the kernel, make any configuration changes, compile it, and then
place it in the proper location on the filesystem to run the system properly. The process
is often automated for you by a shell script or installation program, and some upgrades
are completely automated with no need to do anything more than start the upgrade utility.
Kernel sources for new releases of Linux are available from CD-ROM distributions, FTP
sites, user groups, and many other locations. Most kernel versions are numbered with a
version and a patch level, so you see kernel names like 1.12.123 where 1 is the major
release, 12 is the minor version release, and 123 is the patch number. Most kernel source
sites maintain several versions simultaneously, so check through the source directories
for the latest version of the kernel.
Patch releases are sometimes numbered differently, and do not require the entire source
of the kernel to install. In most cases, the patch overlays a section of existing source
code, and you only need to recompile the kernel to install the patch. Patches are released
quite frequently.
Most kernel source programs are maintained as a gzipped tar file. Unpack the files into
a subdirectory of /usr/src, which is where most of the source code is kept for Linux. Some
versions of Linux keep other directories for the kernel source, so you may want to check
any documentation supplied with the system or look for a README file in the /usr/src
directory for more instructions.
Often, unpacking the gzipped tar file in /usr/src creates a subdirectory called
/usr/src/linux, which can overwrite your last version of the kernel source. Before
starting the unpacking process, rename or copy any existing /usr/src/linux (or whatever
name is used with the new kernel) file so you have a backup version in case of problems.
After unpacking the kernel source, you need to create two symbolic links to the
/usr/include directory (if they are not created already or set by the installation
procedure). Usually, the link commands required are the following:
ln -sf /usr/src/linux/include/linux /usr/include/linux ln -sf /usr/src/linux/include/asm /usr/include/asm
If the directory names are different with your version of Linux, substitute them for
/usr/src/linux. Without these links, the upgrade or installation of a new kernel cannot
proceed.
After ungzipping and untarring the source code and establishing the links, you can
begin the compilation process. You must have a version of gcc or g++ (the GNU C and C++
compilers) or some other compatible compiler available for the compilation. You may have
to check with the source code documentation to make sure you have the correct versions of
the compilers; occasionally new kernel features are added that are not supported by older
versions of gcc or g++.
Check the file /usr/src/linux/Makefile (or whatever path Makefile is in with your
source distribution). This file has a line that defines the ROOT_DEV, the device that is
used as the root filesystem when Linux boots. Usually the line looks like the following:
ROOT_DEV = CURRENT
If you have any other value, make sure it is correct for your filesystem configuration.
If the Makefile has no value, set it as shown in the preceding line.
The compilation process begins with you changing to the /usr/src/linux directory and
issuing the command
make config
which invokes the make utility for the C compiler. The process may be slightly
different for some versions of Linux, so check any release or installation notes supplied
with the source code.
The config program issues a series of questions and prompts you to answer to indicate
any configuration issues that need to be completed before the compilation begins. These
questions may be about the type of disk drive you are using, the CPU, any partitions, or
other devices like CD-ROMs. Answer the questions as well as you can. If you are unsure,
choose the default values or the one that makes the most sense. The worst case is that you
will have to redo the process if the system doesn't run properly. (You do have an
emergency boot disk ready, don't you?)
Next, you have to set all the source dependencies. This step is commonly skipped and can cause a lot of problems if is not performed for each software release. Issue the following command:
make dep
If the software you are installing does not have a dep file, check the release or
installation notes to ensure that the dependencies are correctly handled by the other
steps.
Now you can finally compile the new kernel. The command to start the process is
make Image
which compiles the source code and leaves the new kernel image file in the current
directory (usually /usr/src/linux). If you want to create a compressed kernel image, you
can use the following command:
make zImage
Not all releases or upgrades to the kernel support compressed image compilation.
The last step in the process is to copy the new kernel image file to the boot device or a boot floppy disk. To place the kernel on a floppy disk, use the following command:
cp Image /dev/fd0
Use a different device driver as necessary to place the kernel elsewhere on the hard
drive filesystem. Alternatively, if you plan to use LILO to boot the operating system, you
can install the new kernel by running a setup program or the utility /usr/lilo/lilo. Don't
copy the new kernel over your old boot disk's kernel. If the new kernel doesn't boot, you
may have to use the older boot disk to restart your system.
Now all that remains is to reboot the system and see whether the new kernel loads
properly. If you have any problems, boot from a floppy disk, restore the old kernel, and
start the process again. Check documentation supplied with the release source code for any
information about problems you may encounter or steps that may have been added to the
process.
You may want to link in new device drivers or special software to the kernel without
going through the upgrade process of the kernel itself. This procedure is often necessary
when you add a new device like a multiport board or an optical drive that should be loaded
during the boot process. Alternatively, you may be adding special security software that
must be linked into the kernel.
Add-in kernel software usually has installation instructions provided, but the general
process is to locate the source in a directory that the kernel recompilation process can
find (such as /usr/src). Instructing the make utility to add the new code to the kernel
may require modifications to the Makefile. Either you or an installation script can make
these modifications. Some software has its own Makefile supplied for this reason.
Then, begin the kernel recompilation with the new software added in to the load. The
process is the same as shown in the preceding section, with the kernel installed in the
boot location or set by LILO. Typically, the entire process takes about 10 minutes and is
quite troublefree unless the vendor of the kernel modification did a sloppy job. Make sure
that the source code provided for the modification works with your version of the Linux
kernel.
Most of the software on a Linux system is set to use shared libraries (a set of
subroutines used by many programs). When the message
Incompatible library version
appears on-screen after you upgrade the system and you try to execute a utility, it
means that the libraries have been updated and need to be recompiled. Most libraries are
backwards-compatible, so existing software should work properly even after a library
upgrade.
Library upgrades are less frequent than kernel upgrades and can be found in the same
places. There are usually documents that guide you to the latest version of a library, or
there may be a file explaining which libraries are necessary with new versions of the
operating system kernel. Most library upgrades are gzipped tar files, and the process for
unpacking them is the same as for kernel source code except the target directories are
usually /lib, /usr/lib, and /usr/include. Usually, any files that have the extension .a or
.aa go in the /usr/lib directory. Shared library image files, which have the format
libc.so.version, are installed into /lib.
You may have to change symbolic links within the filesystem to point to the latest
version of the library. For example, if you were running library version libc.so.4.4.1 and
upgraded to libc.so.4.4.2, you must alter the symbolic link set in /lib to this file. The
command would be
ln -sf /lib/libc/so/4/4/1 /lib/libc.so.4
where the last name in the link command is the name of the current library file in
/lib. Your library name may be different, so check the directory and release or
installation notes first.
You will also have to change the symbolic link for the file libm.so.version in the same
manner. Do not delete the symbolic links; if you do, all programs that depend on the
shared library (including ls) will be unable to function.
Linux uses a C compiler for every compilation of the kernel (and most utilities, too).
The C compiler that is available for all versions of Linux is the GNU C compiler,
abbreviated gcc. This compiler was created under the Free Software Foundation's
programming license and is therefore freely distributable. The GNU C Compiler that is
packaged with the Slackware Linux distribution is a fully functional ANSI C compatible
compiler. If you are familiar with a C compiler on a different operating system or
hardware platform, you will be able to learn gcc very quickly.
The GCC compiler is invoked by passing it a number of options and one or more filenames. The basic syntax for gcc is as follows:
gcc [options] [filenames]
The operations specified by the command line options are performed on each of the files
that are on the command line. There are well over 100 compiler options that can be passed
to gcc. You will probably never use most of these options, but you will use some of them
on a regular basis.
Many of the gcc options consist of more than one character. For this reason, you must
specify each option with its own hyphen. You cannot group options after a single hyphen as
you can with most Linux commands. For example, the following two commands are not the
same:
gcc -p -g test.c
gcc -pg test.c
The first command tells gcc to compile test.c with profile information (-p) and also to
store debugging information with the executable (-g). The second command just tells gcc to
compile test.c with profile information for the gprof command (-pg).
When you compile a program using gcc without any command line options, it creates an
executable file (assuming that the compile was successful) and calls it a.out. To specify
a name other than a.out for the executable file, you use the -o compiler option. For
example, to compile a C program file named count.c into an executable file named count,
use the following command:
gcc -o count count.c
As shown in the preceding example, the executable file name must occur directly after
the -o on the command line.
Other compiler options enable you to specify how far you want the compile to proceed.
The -c option tells gcc to compile the code into object code and to skip the assembly and
linking stages of the compile. This option is used quite often because it makes the
compilation of multifile C programs faster and easier to manage. Object code files that
are created by gcc have a .o extension by default.
The -S compiler option tells gcc to stop the compile after it has generated the
assembler files for the C code. Assembler files that are generated by gcc have a .s
extension by default. The -E option instructs the compiler to only perform the
preprocessing compiler stage on the input files. When this option is used, the output from
the preprocessor is sent to the standard output rather than being stored in a file.
When you compile C code with gcc, it tries to compile the code in the least amount of
time and also tries to create compiled code that is easy to debug. Making the code easy to
debug means that the sequence of the compiled code is the same as the sequence of the
source code and no code gets optimized out of the compile. There are many options that you
can use to tell gcc to create smaller, faster executable programs at the cost of compile
time and ease of debugging. Of these options, the two that you will use most are the -O
and the -O2 options.
The -O option tells gcc to perform basic optimizations on the source code. These
optimizations make the code run faster in most cases. The -O2 option tells gcc to make the
code as fast and small as it can. The -O2 option causes the compilation speed to be slower
than it is when using the -O option, but it typically results in code that executes more
quickly.
In addition to the -O and -O2 optimization options, you can use a number of lower-level
options to make the code faster. These options are very specific and should only be used
if you fully understand the effect of these options on the compiled code. For a detailed
description of these options, refer to the gcc man page.
The gcc compiler supports several debugging and profiling options. Of these options,
the two that you are most likely to use are the -g option and the -pg option.
The -g option tells GCC to produce debugging information that the GNU debugger (gdb)
can use to help you to debug your program. The gcc program provides a feature that many
other C compilers do not have. With gcc, you can use the -g option in conjunction with the
-O option (which generates optimized code). This feature can be very useful if you are
trying to debug code that is as close as possible to what will exist in the final product.
When you are using these two options together, be aware that gcc will probably change some
of the code that you have written when gcc optimizes the code.
The -pg option tells gcc to add extra code to your program that, when executed,
generates profile information that the gprof program uses to display timing information
about your program.
Linux includes the GNU debugging program called gdb. You can use gdb debugger to debug
C and C++ programs. It enables you to see the internal structure or the memory that a
program is using while it is executing. This debugging program enables you to perform the
following functions:
When you start gdb, you can specify a number of options on the command line. You will
probably run gdb most often with this command:
gdb filename
When you invoke gdb in this way, you are specifying the executable file that you want
to debug. You can also tell gdb to inspect a core file that was created by the executable
file being examined or attach gdb to a currently running process. To get a listing and
brief description of each of these other options, refer to the gdb man page or type gdb -h
at the command line.
To get gdb to work properly, you must compile your programs so that
the compiler generates debugging information. The debugging information that is generated
contains the types for each of the variables in your program as well as the mapping
between the addresses in the executable program and the line numbers in the source code.
The gdb debugging program uses this information to relate the executable code to the
source code. To compile a program with the debugging information turned on, use the -g
compiler option.
Recompiling the kernel source and adding new features to the kernel proceeds smoothly as long as you know what you are doing. Don't let the process scare you, but always keep boot disks on hand. Follow instructions wherever available as most new software has special requirements for linking into the kernel or replacing existing systems.
